
Remarks 

Informalities 

Supplemental Information Disclosure Statement . Applicant is enclosing herewith a 
supplemental IDS pursuant to 37 C.F.R. §1.97. Please charge the appropriate fee to the deposit 
account identified on the submitted form. 

Petition to Make Special . Applicant is also enclosing a Petition to Make Special the 
above-identified application for patent pursuant to 37 C.F.R. §1.1 02(d). Consideration and 
granting of this petition is respectfiiUy requested. Please charge the appropriate fee to the deposit 
account identified on the submitted form. 

Claim Rejections - 35 U.S.C. S 112 

Claims 1-7 stand rejected under 35 U.S.C. § 1 12, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which appUcant 
regards as the invention. Applicant submits the following to correct this deficiency. 

The preamble recitation in claims 1-7 has been amended to clarify that the present 
invention employs a novel electronic payment system. The Examiner should note that the 
present invention utilizes existing, known payment methods (e.g. paper and electronic 
payments), but employs a new and novel method of carrying these payments out. This 
amendment to the claims does not alter the scope of the claims to come within Festo, but merely 
serves to remove the vague and confiising language as indicated by the Examiner. 

Claim Rejections - 35 U.S.C. S 103 

Claims 1-7 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over United 
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States Patent No. 6,058,380 to Anderson at al., in view of United States Patent No. 6,018,736 to 
Gilai et al. In light of the above-identified amendments and the arguments as presented below, 
Applicant submits that Anderson, in view of Gilai, does not render the present invention obvious 
and that the rejection should be withdrawn. 

Anderson discloses a system and method for electronically processing invoice 
information. Although seemingly similar, Anderson is quite distinct from the present invention. 
Perhaps the biggest distinction is that Anderson requires an intermediary to perform the methods 
disclosed. Specifically, Anderson requires an intermediary to gather invoice and other relevant 
accounts payable information, which is then used to direct payment to the vendors whose 
invoices were submitted. The intermediary in Anderson is the central focus of the invention and 
performs the majority of tasks disclosed. Anderson allows customers who are not EDI capable to 
pay vendors electronically because vendor invoices are delivered to the intermediary through 
traditional means, such as mail drop, etc. Once the intermediary has the invoices, payment can 
be made through electronic means or a check can be prepared, which can be mailed to the vendor 
upon approval by the customer. The customer is not required to be EDI capable because the 
intermediary takes care of payment after the customer approves the transaction. See Anderson 
Col. 8, In. 57-67. Claim 1 of the present invention has been amended to clarify this point. 
Specifically, claim 1 has been amended to make it clear that the method of the present invention 
is substantially performed on the system of the user. No new matter has been introduced as 
support for the amendment is foxmd in the specification. In addition, the amendment is meant 
only to clarify the scope of the invention, thus neither narrowing nor broadening the claim to 
come within the meaning of Festo. 

Another critical difference is that there is no "determination" function being performed 
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by the invention in Anderson. Specifically, each payment method is pre-determined in the setup 
process, thus negating the method of the present invention, whereby a particular payment method 
is actually determined, e.g., electronic or traditional, based upon certain vendor criteria. See 
Anderson col. 10, ,bi. 8-11; col. 13, hi. 20-67. Anderson does not teach a method for determining 
which type of payment a vendor is capable of receiving, as does the computer program of the 
present invention, but rather provides a method for using an intermediary, in conjunction with 
various customers and vendors who are all linked to the intermediary, to process and pay 
outstanding invoices. 

The use of an intermediary in this fashion directly teaches away fi-om the present 
invention. Moreover, the intermediary in Anderson requires each customer to submit their 
invoices to the intermediary, which then is responsible for paying each vendor. In this respect, 
the customer is taken out of the picture, other than to provide the intermediary with the necessary 
data to complete the transaction. This is quite distinct from the present invention. The present 
invention allows the customer, or user, to monitor, track, and pay vendors without having to use 
an intermediary. Although an intermediary, such as a service center, may be used to process and 
send paper checks to those vendors incapable of receiving electronic payments, this use is 
distinctly different than the intermediary in Anderson. The intermediary, as described in the 
present invention is merely a processing center and nothing more. It does not serve to gather 
information from both the customer and the vendors and then proceed to pay the vendors 
according to this information, as the intermediary does In Anderson. In essence, the present 
invention operates firom the standpoint of the customer or user, with little or no interaction with 
the vendor. For example, in Anderson all invoices are directed to the intermediary, not the 
customer, which then matches the invoices with vendor information and takes care of appropriate 
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payment. In the present invention, all invoices, etc., are still directed to the customer, who can 
then use the technology of the present invention to pay vendors. This significantly reduces 
operating expenditures and other personnel that would be required to operate an intermediary as 
in Anderson. Anderson does not suggest, nor teach that the customer can direct payment to 
several vendors using electronic means, but rather teaches the use of an intermediary, in 
conjunction with the customer and vendors each submitting pertinent information to the 
intermediary, to handle payment to the vendors. 

Moreover, claim 1 has been amended to include the association and transmission of 
available remittance data with the payment transaction. Such a limitation is not taught nor 
suggested by the Anderson reference. 

In addition to the foregoing, claims 8 and 9 have been added to further clarify and define 
the teaching of the present invention. No new matter has been introduced and each element is 
supported in the specification. Specifically, claim 8 recites a remittance delivery system to be 
used in conjunction or submitted with the payment transaction. Anderson does not disclose this, 
nor teach the transmission of remittance data with an electronic payment. Claim 9 recites a 
method for paying a vendor and transmitting remittance data using an electronic system. Claim 
9 is similar to claim 1, but includes other limitations not recited in claim 1. 

In light of the arguments above and the fact that Anderson does not suggest, nor teach, 
but in fact directly teaches away from that claimed in the present invention. Applicant submits 
that rejection in light of the Gilai reference is moot. Combination of these two references does 
not render the present invention obvious. 
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Version with Markings to Show Changes Made 
1 . iA method for electronically determining, i n an electronic payment system,-a 
metliod f o r d et emiining which of a plurality of payment methods is to be employed for at least 
one vendor to be paid, said method comprising the steps of:. 

a) receiving from a user at least one vendor identifier for each of said at least one 

vendor; 

b) consulting a vendor database for a vendor database identifier corresponding to 

said vendor identifier; 

c) when said vendor database includes said vendor identifier, retrieving a preferred 

payment method identifier corresponding to said vendor database 
identifier as stored in said vendor database; 

d) when said vendor database does not include a match of said vendor identifier, 

from said vendor identifier phonetically matching to said vendor database 
identifier as stored in said vendor database and retrieving said preferred 
payment method identifier; and 

e) presenting to said user said vendor database identifier in a list corresponding to 

said preferred payment method identifier: 
wherein said method is substantially performed and controlled by the computer system of said 
user. 

2^ The method as recited in claim 1, wherein said step of r eceiving from a user mi at 
least one vendor identifier for each of said at least one vendor step, comprises the step of 
receiving said at least one vendor identifier for each of said at least one vendor from an accoimts 
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payable database created and maintained by an accounting software application. 

3. In an e l e cti -o nic p ayment system, t The method for de te rmining wliich of a 
plurality o f payment m e tliods t o b e employed for at leas t o n e v e nd o r t o be paid, as recited in 
claim 1, further comprising the step of defining said plurality of payment methods to include 
traditional check drafting and electronic payment methods. 

4. In an el e ctronic paym e nt sys t em, th e me t hod f o r d e t e rmining which o f a plurali t y 
o f paym e nt metliods to be e mpl o yed fo r at l e ast o n e vend o r to be paid. The method as recited in 
claim 1, wherein said step of presenting to said user said vendor database identifier in a list 
corresponding to said preferred payment method identifier-step fiirther comprises the step of 
when one of said at least one vendor to be paid is proposed for payment using one of said 
plurality of payment methods, reassigning said one of said at least one vendor to another of said 
plurality of payment methods. 
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5 . Ill ail clcc t rDmc payment system, t The method for d e t e rmining wliieh o f a 
plurali t y of payment metliods t o be e mploy e d for at leas t o n e v e ndor t o be paid, as recited in 
claim 1, wherein said presenting to said user said vendor database identifier in a list 
corresponding to said preferred payment method identifier step fiirther comprises the steps of: 

a) fi-om an identifier of said at least one vendor supplied by said user, referencing a 

database to determine which entries of said database correspond 
identically or most closely to said at least one vendor supplied by said 
user; 

b) when said electronic payment system locates an exact match of said identifier of 

said at least one vendor, presenting said at least one vendor in normal text 
to said user for verification; and 

c) when said electronic payment system finds no exact match of said identifier of 

said at least one vendor, selecting one of said at least one vendor as an 
approximation of said identifier designating said one 

6. Ill an e lec t r o nic payment system, tThe method d e termining wliich o f a plurali t y o f 
paym e nt m e thods t o be employ e d for a t leas t one vend or t o be paid, as recited in claim 5, 
wherein said selecting said at least one vendor as an approximation of said identifier step fiirther 
comprising the step of when one of said at least one vendor is presented conspicuously fi-om 
normal, allowing said user to evaluate said approximation to determine if said approximation of 
said identifier accurately reflects said one of said at least one vendor desired by said user. 
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7. Ill All e l e cti 'o iiic paym e nt system, t The method d e t e rmining wliicli of a plurality of 
paymen t m e thods t o b e employ e d f o r a t least one vend o r, to b e paid, as recited in claim 1 , further 
comprising the step of receiving a hst of said at least one vendor as output from an accounting 
sofhvare application independent from said electronic payment system. 

8. A remittance delivery system, comprising: 

a remittance preference database storing information pertaining to at least one remittance 
recipient: 

a translation engine for receiving preferred payment information data and remittance data 
and translating and formatting said remittance data into one of a plurality of 
preferred formats; and 

a remittance generating engine that receives said formatted remittance data and forwards 
said formatted remittance data to said at least one remittance recipient based on 
the information stored in said remittance preference database. 

9. A method for paying a vendor and transmitting remittance data using an electronic 
system, said method comprising the steps of: 

receiving an outstanding invoice from at least one vendor: 

processing said nivoice tlirough a computerized accounting application program to output 

accounts payable check data: 
assigning said at least one vendor a vendor identifier: 

based upon said accounts payable check data, determining whether to pay said vendor by 
paper check or electronically by consulting a vendor database for a vendor 
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database identifier corresponding to said vendor identifier; 
when said vendor database includes said vendor identifier, retrieving a preferred payment 
metliod identifier corresponding to said vendor database identifier as stored in 
said vendor database: 

when said vendor database does not include a match of said vendor identifier, fi:'om said 
vendor identifien phonetically matching said vendor database identifier as stored 
in said vendor database an subsequently retrieving said preferred payment method 
identifier: 

presenting to said user said vendor database identifier in a list corresponding to said 

preferred payment method identifier: 
paying said vendor according to said payment method identifier: 
storing, in a remittance preference database, remittance data pertaining to at least one 

remittance recipient: 

translating and formatting, via a translation engine, said remittance data into one of a 

plurality of preferred formats: and 
forwarding, via a remittance generating engine, said formatted remittance data received 
fi-om said translation engine to said at least one remittance recipient based on the 
information stored in said remittance preference database: 
wherein said method is substantially perfomied and controlled by the computer system of said 
user. 



- 14- 




Conclusion 



Based on the foregoing explanation and amendments to the claims, Applicant submits 
that the rejections under §§112 and 103 have been overcome and that the claims now stand in 
condition for allowance. 

If any impediment to the allowance of this application remains after entry of these 
amendments and consideration of these remarks, the Examiner is invited to initiate a telephonic 
interview with the undersigned. 

DATED this day of August, 2001. 




Respectfiilly Submitted, 




McCONKIE 



Attomey for Applicant 
Registration No. 35,232 
KIRTON <aMcCONKIE 
1800 Eagle Gate Tower 
60 East Soutn Temple 



Salt Lake City, UT 84111 
(801) 328-3600 
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